here, we are decoding the structured body into a payload body, but we are still wrapping the response with the original Content-Length header. we should add an override to DecodedResponse for the getHeaders method where we remove the Content-Length header:

@Override
public HttpHeaders getHeaders() {
    HttpHeaders headers = new HttpHeaders(originalResponse.getHeaders());
    headers.remove(HttpHeaderName.CONTENT_LENGTH);
    return headers;
}

another option is to use the adjusted Content-Length value, but I'm not sure if we know that until everything is consumed.

This is done

@ibrandes and @gunjansingh-msft I'm not sure if I'm following why we'd remove the Content-Length header all together? My main concern is that using the Content-Length header is a common way to derive the size of blob that is being downloaded and downstream logic might rely on it being present? Might be interesting to check with what .NET does here as well to make sure we are consistent. I do generally agree that it makes sense to override the Content-Length with the value of the x-ms-structured-content-length in order to not break existing flows that leverage content length as the blob size.

I’ve aligned this with the .NET behavior in the latest revision.

In the .NET SDK, the response body is wrapped via StructuredMessageDecodingStream.WrapStream, but the response headers (including Content-Length) are not modified and continue to reflect the wire payload size.

I’ve removed the Content-Length override here as well, so the Java implementation now matches the .NET and by passing headers through unchanged.

Callers can still get the decoded length via x-ms-structured-content-length, BlobDownloadHeaders.getBlobSize(), or Content-Range if needed.

adding this as an ADO item to further investigate.

@ibrandes and @gunjansingh-msft I'm not sure if I'm following why we'd remove the Content-Length header all together? My main concern is that using the Content-Length header is a common way to derive the size of blob that is being downloaded and downstream logic might rely on it being present? Might be interesting to check with what .NET does here as well to make sure we are consistent. I do generally agree that it makes sense to override the Content-Length with the value of the x-ms-structured-content-length in order to not break existing flows that leverage content length as the blob size.

Were we planning to remove this method per this comment? #47016 (comment) Mainly asking, fine to defer it for a follow up task like we are doing for the content length.

yep - thanks for catching this! looks like i accidentally reverted the removal :,)